How  to  Move  Your  Part  of  the  Program  Forward 

Chad  Millette 


As  an  instructor  for  the  Air  Force  Institute  of  Technology's  Intermediate  Project  Manage¬ 
ment  class  (IPM  301),  I  sometimes  hear  students  express  deep  frustration  with  their 
seeming  inability  to  make  any  positive  progress  on  their  programs.  In  a  recent  presenta¬ 
tion,  retired  Air  Force  Lt.  Col.  Dan  Ward  fielded  several  questions  from  junior  program 
managers  (PMs)  about  what  they  could  do  to  make  a  difference  in  their  programs. 
Ward's  responses  echoed  good  advice  I  received  during  my  career,  which  I  was  inspired  to  share. 

As  PMs  in  the  Department  of  Defense  (DoD),  we  often  struggle  with  how  much  control  we  feel  we  have  (or  don't 
have)  over  our  programs.  Although  we  are  project  managers,  we  don't  really  manage  the  projects  day  to  day;  we 
hire  defense  contractors  and  rely  on  them  to  manage  their  projects.  We  often  come  into  very  large  programs 
somewhere  in  mid-execution  and,  depending  on  our  tenure  in  the  program  office,  we  often  leave  somewhere  in 
mid-execution— with  the  program  hopefully  closer  to  completion  than  when  we  arrived.  It  can  prove  frustrating  not 
to  have  been  in  at  the  beginning  and  to  have  to  live  with  the  results  of  decisions  made  earlier.  The  contractor  often 
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The  support  contractor  was  telling  me  that  worrying  about  things  over 
which  I  had  no  control  will  result  in  frustration  and  that  I  needed  to 
focus  my  energies  on  the  part  of  the  program  I  could  control. 


seems  unresponsive.  The  budget  is  in  peril  continuously.  And 
no  matter  what  we  do,  the  program  doesn't  seem  to  improve. 
How  is  a  PM  to  remain  positive,  upbeat  and  engaged? 

I  experienced  just  this  type  of  frustration  when  I  was  a  major 
assigned  as  a  PM  on  a  multibillion-dollar  satellite  system  de¬ 
velopment  program.  This  program  could  be  considered  both 
a  Death  March  and  a  Death  Star  program.  Edward  Yourdon 
defines  a  Death  March  program  as  "one  for  which  an  unbiased, 
objective  risk  assessment  determines  that  the  likelihood  of 
failure  is  >  [greater  than]  50  percent."  Success,  in  this  case, 
is  defined  by  the  traditional  constraints  of  cost,  schedule,  and 
performance  and  quality— delivering  the  user's  required  capa¬ 
bility  on  time  and  on  cost.  Ward  says  a  Death  Star  program  is 
"any  enormous  project  that  is  brain-meltingly  complex,  raven¬ 
ously  consumes  resources,  and  aims  to  deliver  an  Undefeat- 
able  Ultimate  Weapon."  (See  Ward's  article  "Don't  Come  to 
the  Dark  Side,"  Defense  AT&L,  September-October  2011.)  The 
program  I  was  working  on  fit  both  of  those  definitions.  And 
let  me  tell  you,  when  the  two  most  apt  characterizations  of 
your  program  include  the  word  "death,"  it  can  make  for  a  very 
frustrating  experience. 

Shortly  after  I  arrived,  the  program  experienced  its  second 
Nunn-McCurdy  breach.  (A  Nunn-McCurdy  breach  occurs 
when  an  acquisition  program  experiences  a  25  percent  or 
greater  increase  over  the  current  Acquisition  Program  Baseline 
(APB)  objective  and/or  a  50  percent  or  greater  increase  over 
the  original  APB  objective.)  Several  years  behind  schedule  and 
millions  of  dollars  over  budget,  the  program  seemed  doomed 
to  fail.  The  program  originally  was  awarded  as  a  total  system 
performance  responsibility  (TSPR)  contract,  and  the  program 
office  and  contractor  had  what  could  best  be  described  as  a 
tense  relationship.  At  one  point,  the  government  zeroed  out 
the  award  fee  on  the  contract. 

I  was  not  the  program  director  (i.e.,  the  overall  PM);  I  was 
assigned  subsystem  management  responsibilities  (database, 
flight  software  and  ultimately  the  spacecraft  subsystem). 
However,  as  a  junior,  still-motivated  PM,  I  desperately  wanted 
to  make  a  difference  in  turning  the  ship  around.  At  one  of  my 
lowest  points  in  terms  of  motivation,  I  expanded  upon  the  idea 
of  the  ship  analogy. 

I  had  a  whiteboard  in  my  office.  One  day,  I  drew  a  large  sailing 
ship  with  two  masts  and  labeled  the  ship  the  S.S.  Program.  I 
drew  water  underneath  the  ship  with  a  big  arrow  that  showed 
the  direction  the  water  was  taking  us  and  I  labeled  the  water  as 
the  contractor.  I  drew  clouds  in  the  sky  above  the  ship  with  ar¬ 
rows  indicating  the  wind  and  labeled  this  as  Congress.  I  added 


a  rudder  to  the  back  of  the  ship  and  labeled  it  the  program 
director.  Finally,  I  drew  a  porthole  in  the  side  of  the  ship  with 
an  oar  sticking  out  of  it,  and  I  labeled  that  as  me. 

I  would  explain  to  visitors  that  the  cartoon  depicted  how  I  felt 
about  the  program.  The  contractor  takes  the  program  along 
a  strong  current  and  seems  to  be  the  greatest  determinant  of 
where  the  program  is  going.  Sometimes  the  political  winds 
would  change  our  direction  or  our  speed.  The  program  direc¬ 
tor  can  make  programmatic  course  corrections  and  influence 
the  direction  we  take  (i.e.,  acts  as  the  rudder).  And  finally, 
I'm  the  guy  sticking  his  oar  out  into  the  water  to  influence  the 
program's  speed  or  direction.  I  would  tell  people  that  I  felt  like 
every  time  I  stuck  my  oar  in  the  water,  it  would  break.  I  would 
then  go  back  and  get  another  one  and  stick  it  in  the  water,  only 
to  have  it  break  again. 

I  was  pretty  proud  of  myself  for  coming  up  with  such  a  pow¬ 
erful  analogy  that  represented  not  only  my  frustrations,  but 
apparently  those  of  many  colleagues  as  well.  As  people  would 
stop  by  to  hear  my  explanation  of  the  drawing,  I  found  that  the 
analogy  resonated  with  them.  In  fact,  some  even  added  to  it. 
One  of  my  co-workers  drew  the  water  ending  at  a  steep  water¬ 
fall  and  labeled  it  the  "Cliffs  of  Insanity."  Another  drew  rocks 
at  the  bottom  of  the  waterfall  showing  how  perilous  would  be 
the  journey  over  the  edge.  Finally,  another  drew  a  little  boat 
popping  up  out  of  the  water  and  labeled  it  the  alternative  to 
our  program  that  the  Air  Force  was  considering. 

This  kind  of  dark  humor  is  common  in  many  program  offices— 
and  that  is  one  reason  "Dilbert"  cartoons  are  featured  promi¬ 
nently  on  so  many  cubicle  walls.  Wallowing  in  misery,  however, 
isn't  healthy.  A  telltale  sign  of  a  Death  March  project  is  when 
the  humor  gets  to  the  depths  of  the  graphic  I  drew  on  my 
whiteboard.  I  found  I  was  retelling  the  narrative  and  adding  to 
it  frequently  over  the  course  of  a  month  or  so.  I  wasn't  getting 
any  closer  to  fixing  the  program  or  reducing  my  frustration, 
but  explaining  the  graphic  gave  me  an  outlet  and  an  ability  to 
commiserate  with  my  teammates.  Ultimately,  I  was  confronted 
by  someone  who  didn't  want  to  share  my  analogy  but  to  put 
me  on  the  right  track. 

A  wise  retired  senior  officer  who  was  a  support  contractor  for 
the  program  came  in  one  day,  looked  at  my  whiteboard  and 
shut  the  door.  She  had  heard  about  the  drawing  and  came  to 
see  it  herself.  She  listened  intently  as  I  boasted  about  how 
closely  the  situation  I  had  drawn  on  the  board  matched  the 
real  world  in  the  program  office.  When  I  finished,  I  noticed 
she  was  scowling.  What  she  said  caught  me  a  little  off  guard 
because  of  both  her  tone  and  direct  approach.  She  said,  "You 
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moron!  Of  course  you  can't  change  the  direction  of  this  pro¬ 
gram.  This  program  is  huge.  Your  job  is  to  do  the  best  you  can 
with  the  part  of  the  program  that  you  are  assigned.  Worry 
about  the  cost,  schedule  and  performance  of  your  piece  of  the 
program  and  let  the  leadership  deal  with  the  bigger  picture." 
She  walked  out  chuckling  and  sarcastically  muttering,  "My  oar 
keeps  breaking  ...  give  me  a  break." 

I  thought  about  what  she  said  and  realized  she  was  right.  Mil- 
lette  couldn't  fix  this  program— moreover,  doing  so  wasn't  my 
job!  My  job  was  to  ensure  that  my  subsystem  met  the  user's 
requirements  affordably  and  was  ready  when  the  program 
needed  it.  The  support  contractor  was  telling  me  that  wor¬ 
rying  about  things  over  which  I  had  no  control  will  result  in 
frustration  and  that  I  needed  to  focus  my  energies  on  the  part 
of  the  program  I  could  control.  I  didn't  connect  the  dots  at  the 
time,  but  I  have  come  to  realize  that  her  advice  was  in  con¬ 
cert  with  what  Stephen  Covey  called  the  "Circle  of  Concern/ 
Circle  of  Influence"  in  his  seminal  book  The  7  Habits  of  Highly 
Effective  People. 

Within  an  acquisition  program  context,  Covey's  paradigm  sug¬ 
gests  that  the  broader  scope  of  the  entire  program  would  be  in 
our  Circle  of  Concern— i.e.,  things  we  have  no  real  control  over 
and  can't  do  anything  about.  Many  PMs  can  feel  trapped  when 
they  focus  their  energy  in  the  Circle  of  Concern— things  like 
the  weaknesses  of  other  people  and  problems  in  the  program 
environment.  PMs  stuck  here  are  characterized  by  negative  at¬ 
titudes  and  language  and  feelings  of  victimization.  Constantly 
focusing  on  these  areas  increases  feelings  of  helplessness. 
Such  are  the  feelings  expressed  in  the  S.S.  Program  graphic  on 
my  whiteboard  and  those  that  my  IPM  301  students  describe 
when  they  bemoan  their  individual  situations. 

However,  there  is  a  smaller  circle  inside  the  Circle  of  Concern 
where  we  can  make  a  difference  because  we  do  have  the  re¬ 
sponsibility  and  authority;  this  is  the  Circle  of  Influence.  My 
sage  advisor  was  suggesting  that,  instead  of  being  frustrated 
because  of  my  inability  to  fix  the  program  as  a  whole— cer¬ 
tainly  inside  my  Circle  of  Concern,  but  not  in  my  Circle  of  In¬ 
fluence— I  needed  to  focus  on  fixing  the  part  of  the  program 
for  which  I  did  have  responsibility,  my  own  little  subsystem. 

Covey  would  suggest  that  PMs  can  recognize  when  they  are 
in  the  Circle  of  Concern  when  they  have  thoughts  such  as:  "If 
only  I  had  clearer  requirements,"  "I  could  do  a  better  job  if  I 
had  a  more  stable  budget"  or  "if  I  had  more  time  to  mature 
the  technology."  Notice  the  tone;  the  Circle  of  Concern  is  filled 
with  haves.  On  the  other  hand,  the  Circle  of  Influence  is  filled 
with  be's:  "I  can  be  more  engaged  with  my  user,"  "I  can  be  a 
positive  influence  on  my  contractor  counterpart,"  "I  can  be  the 
one  to  craft  a  flexible  acquisition  strategy." 

Covey  suggests  that  PMs  have  problems  in  one  of  three 
areas:  direct  control  (problems  involving  our  own  behavior); 
indirect  control  (problems  involving  other  people's  behavior); 
or  no  control  (problems  we  can  do  nothing  about).  PMs  can 


solve  the  direct  control  problems  by  improving  their  habits— 
i.e.,  what  they  do.  PMs  don't  solve  indirect  control  problems 
themselves;  rather,  they  change  their  methods  of  influence 
to  work  with  people  to  solve  the  problem.  Finally,  PMs  don't 
solve  the  "no  control"  problems  at  all;  they  resign  themselves 
to  "genuinely  and  peacefully  accept  these  problems  and  learn 
to  live  with  them,"  even  though  they  don't  like  them  (think  of 
the  Alcoholics  Anonymous  serenity  prayer). 

On  my  program,  I  dealt  with  my  "direct  control"  problems 
through  weekly  discussions  with  my  contractor  counterpart 
about  issues  with  our  subsystem  development.  Also,  I  re¬ 
signed  myself  to  get  smarter  on  earned  value  management 
and  dig  deeper  into  the  earned  value  reporting  we  received. 
To  handle  "indirect  control"  problems,  I  got  together  with 
the  other  majors  who  were  subsystem  PMs  and,  rather  than 
commiserating,  we  came  up  with  integration  forums  where 
we  could  discuss  key  aspects  of  how  our  subsystem  develop¬ 
ments  interacted  with  each  other.  Having  been  put  on  the  right 
course  by  my  sage  counselor,  I  stopped  fretting  about  aspects 
of  the  program  outside  my  span  of  control  (the  "no  control" 
problems).  I  kept  aware  of  what  was  going  on— but  only  as  a 
means  of  being  prepared  in  the  event  of  an  impact  to  my  area. 

When  I  first  started  on  the  program,  there  was  talk  that  the 
satellite  was  3  to  4  years  from  launch.  I  spent  4  years  assigned 
to  the  program  in  various  capacities— a  tour  I  joke  ought  to 
make  me  eligible  for  the  acquisition  equivalent  of  the  Purple 
Heart.  When  I  left  the  program,  it  was  still  about  2  to  3  years 
from  launch.  In  the  end,  the  satellite  did  launch  2  years  after 
I  left.  By  all  accounts,  the  satellite  system  is  performing  at  or 
above  the  user's  expectations.  Although  it  was  at  times  a  very 
frustrating  assignment,  it  was  also  incredibly  rewarding.  And 
looking  back,  my  frustration  could  have  been  reduced— and 
ultimately  was  with  the  helpful  advice  of  a  veteran  PM— with 
some  perspective  about  what  was  and  was  not  in  my  circle 
of  control. 

During  that  recent  speaking  engagement,  Ward  responded 
to  a  young  PM's  questions  with  advice  similar  to  what  I  tell 
my  students  who  ask  what  they  can  do  when  they  feel  in¬ 
creasingly  frustrated.  Ward  reminded  the  PMs  that  no  matter 
where  in  the  life  cycle  their  program  is  and  how  late  or  over 
budget  it  might  be,  there  are  decisions  to  be  made  about 
the  future  direction  of  their  piece  of  the  program.  I  tell  my 
students  that,  with  the  added  tools  we  provide  them  in  IPM 
301,  they  can  now  ask  better  questions  and  dig  a  little  deeper 
into  the  program  status  and  progress.  It  is  the  government 
PM's  job  to  evaluate  the  situation  and  make  decisions  with 
the  best  chance  of  righting  the  portion  of  the  ship  for  which 
they  are  responsible.  I  believe  that,  if  this  tack  is  taken  by 
everyone  in  the  program  office,  pretty  soon,  the  Death  March 
and  Death  Star  dark  humor  talk  around  the  program  office 
will  subside  as  all  hands  are  motivated  to  do  their  part  to  help 
the  program  succeed.  & 

The  author  can  be  contacted  at  millettes@sbcglobal.net. 
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